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(54) Intelligent network internetworking access arrangement 



(57) All existing services than can be offered in one 
telecommunication network can be offered across net- 
works (A,B) without changing any existing interfaces 
and protocols. A mediation access processor (MAP) 
(304) is provided in a network element located in a first 
network (B) that is interconnected with a second net- 
work (A). The MAP (304) provices screening, translation 



and emulation functionality so that (a) messages trans- 
mitted between switches (306) in the first network and 
SCP's or other application processors (302) in the sec- 
ond network can be properly converted so as to be rec- 
ognized and understood, and (b) changes to the inter- 
communication arrangements of the switches and the 
SCP's, such as the protocols that are supported, are not 
necessary. 
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Description 

Field of the Invention 

The present invention relates generally to the inter- 
connection of elements in different telecommunications 
networks, and, in particular, to the provision of intelligent 
network supported services across network boundaries. 
The present invention also contemplates an arrange- 
ment by which elements in different networks may be 
interconnected so that, for example, a switch disposed 
in one network may communicate with a controlling 
computer, such as a service control point (SCP) in an- 
other network. 

Background of the Invention 

The Intelligent Network (IN) is the name given to a 
collection of network elements, including (a) service 
switching points (SSP's), that are also commonly re- 
ferred to as switches, (b) controlling computers, such as 
a service control points (SCP's), and (c) voice process- 
ing and announcement platforms and messaging plat- 
forms, which are collectively sometimes referred to as 
intelligent peripherals (IP's). The enumerated elements, 
as well as other known network elements, must effec- 
tively communicate with each other in order to provide 
centralized support and rapid introduction of a wide 
range of telecommunications services. The functionality 
provided to a given intelligent network call is ascertained 
by executing service logic programs stored in different 
network elements and controlled in an SCP. As long as 
the elements involved in processing a given call are part 
of the same network, provision of such services is con- 
venient and feasible, because the intra-networking in- 
terfaces between the elements, which may be provided 
by different vendors, are standardized. For example, 
messages that invoke the service logic programs can 
be transmitted from the switch that receives a call, to the 
SCP in the same network that contains the service logic 
program, via a Signaling System No. 7 (SS7) message 
transmitted in the Intelligent Network Applications Part 
Protocol (I NAP) format. 

When the elements that are involved in processing 
a given call are not part of network in which the switch 
processing the call is located, the provision of intelligent 
network supported services is more complicated. The 
complications arise from the fact that the network pro- 
viders are reluctant to allow their switches to receive call 
processing instructions from an element outside of their 
own networks, due, at least in part, to potential problems 
that can arise due to interconnection and that may jeop- 
ardize switch integrity. Different network providers are 
also unwilling or unable to convert the elements in their 
networks to handle protocols used by other networks. 
For example, certain networks are maintained by in- 
terexchange carriers (IXC'S), such as AT&T, MCI and 
Sprint; other networks are maintained by local exchange 



carriers (LEC's) and regional Bell operating companies 
(RBOC's), such as Bell Atlantic and NYNEX, respective- 
ly, and yet other elements involved in supporting intelli- 
gent network services are maintained by service provid- 
5 ers that do not own networks, such as utility companies. 
Presently, the interfaces between IN network ele- 
ments in the same network are implemented or support- 
ed by a standardized protocol, known as I NAP (part of 
the ITU Capability Set 1 (CS-1) intelligent network rec- 
10 ommendations). However, INAP cannot be used to im- 
plement acceptable interconnection between a switch 
in one network and a database in a foreign network. 
Present arrangements allow a service control function 
(SCF) part of an SCP in one network to launch a query 
'5 directly to a service data function (SDF) part of an SCP 
in another network. However the information obtained 
in response to such a query is very limited, and is service 
independent. This existing query capability thus does 
not allow the provision of intelligent network services 
across networks. 

Presently, regulatory bodies in various foreign 
countries (as well as in the United States) require net- 
work operators to open their networks to independent 
service providers. However such openness has not yet 
been achieved. The present invention provides the tech- 
nical details for achieving such openness. 

Summary of the Invention 

I have recognized the need for an open inter-net- 
working interface that does not jeopardize switch integ- 
rity and at the same time requires no changes to the 
existing standards and implementations. The interface 
must be flexible as far as physical implementation is 
concerned, must take account of integrity concerns, 
must solve the issue of the use of different INAP options 
by the involved networks, and. most importantly, must 
preserve existing implementations, which conforming to 
existing standards, such as CS-1 and pre-standard (e. 
g., AIN 0.1, ETSI Core INAP) implementations. 

In accordance with the present invention, all exist- 
ing services that can be offered in one network can be 
offered across networks without changing any existing 
interfaces and protocols. A mediation access processor 
(MAP) is provided in a network element located in a first 
network that is interconnected with a second network. 
The MAP provides screening, translation and emulation 
functionality, so that (a) messages transmitted between 
switches in the first network and SCP's or other appli- 
cation processors in the second network can be properly 
converted so as to be recognized and understood, (b) 
changes to the intercommunication arrangements of the 
switches and the SCP's , such as the protocols that are 
supported, are not necessary. 

Brief Description of the Drawing 

The present invention will be more fully appreciated 
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by consideration of the following detailed description 
which should be read in light of the accompanying draw- 
ings in which: 

Fig. 1 is a block diagram illustrating the convention- 
al interconnection among various network elements 
in a single communication network: 

Fig. 2 is a block diagram illustrating how the various 
network elements of Fig. 1 would be conventionally 
interconnected with similar elements in a second 
communication network; 

Fig. 3 is a diagram illustrating the arrangement of a 
MAP in accordance with the present invention, to 
interface between a SCF in a first network and an 
SSF/CCF in a second network; 

Fig. 4 is a block diagram illustrating the arrange- 
ment of the modules within MAP 304 of Fig. 3: 

Fig. 5 is a diagram illustrating the process per- 
formed in MAP 304 of Fig. 3 when it receives a mes- 
sage from SCF 302 in Network A of Fig. 3; and 

Fig. 6 is a diagram illustrating the process per- 
formed in MAP 304 of Fig. 3 when it receives a mes- 
sage from SSF/CCF 306 in Network B of Fig 3 
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Detailed Descri ption 

Referring first to Fig. 1 , there is shown a block dia- 
gram illustrating the conventional interconnection 
among various network elements in a single communi- 
cation network. Fig. 1 thus illustrates the current state 
of the industry agreement on interfaces and reflects the 
- r J TU " T Fiecommendations Q.1214and Q.1211 
"p In Fig. 1, SSP 112, which may be a 5ESS® program 
controlled electronic switching system available from 
AT&T Corp. , includes a pair of modules that have differ- 
- ent functions, namely an SSF module 116 performing a 
service switching function and a CCF module 114 per- 
forming a call control function. A controlling computer or 
service control point (SCP) 130, which may be an A-l- 
NET® SCP available from AT&T Corp., also includes a 
pair of modules that have different functions, namely an 
SCF module 1 08 performing a SCF service control func- 
tion, which is responsible for the execution of Service 
Logic Programs (SLP's), and an SDF module 110 per- 
forming a service data function. Basically, SDF module 
110 is merely a service-independent data repository. 

In Fig. 1, an intelligent peripheral (IP) 120 can in- 
clude an SRF module 118 arranged to perform a spe- 
cialized resources function. Such a function can, for ex- 
ample, be performed by an A-I-NET SCN (service con- 
trol node) available from AT&T Corp. 

Three additional modules are shown in Fig. 1, in- 
cluding an SMF module 104 that performs a service 
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management function, an SCEF module 102 that per- 
forms a service creation environment function and a 
SMAF module 1 06 that performs a service management 
agent function. These modules have no standardized 
interfaces to the rest of the remaining modules shown 
in Fig. 1. Rather, these modules or elements are inter- 
connected by proprietary means, so that these modules 
and interfaces cannot be used consistently in multi-net- 
work or multi-service-provider environments Thus only 
the SCF-to-SDF, SCF-to-SSF/CCF, and SCF-to-SRF in- 
terfaces have been standardized; together, these inter- 
faces constitute the Intelligent Network Application Part 
Protocol (INAP) S which does promote inter-vendor op- 
erability. Notwithstanding the foregoing, these interfac- 
es do not meet inter-networking requirements, as will be f 
seen more clearly in connection with Fig. 2. j 

Fig. 2 is a block diagram illustrating how the various 
network elements of Fig. 1 would be conventionally in- 
terconnected with similar elements in a second commu- 
nication network. On the left hand portion of Fig. 2 a 
first network, Network A, includes all of the elements 
shown in Fig. i. On the right hand portion of Fig. 2, a 
second network, Network B, also includes all of the el- 
ements shown in Fig. i. Note here that it is not neces- 
sary that Networks A and B have identical elements 

As shown in Fig. 2, the only inter-networking inter- 
faces between elements in Networks A and B are (a) 
the interface 250 between SCF 208 and SDF 244. and 
(b) the interface 251 between SCF 230 and SDF 220 
These interfaces use the INAP protocol, as set forth in 
ITU-T Recommendations Q.1211 and Q.1218. These 
interfaces are limited to the extension of database que- 
ries from the SCF to the connected SDF and to the 
transmission of query responses from the SDF back to 
the SCF These interfaces specifically exclude any ex- 
change of service-related information, since all such in- 
formation is, by definition, contained in the SCF. 

The existence of such interfaces, which are in fact 
very limited, does not allow a service provider to offer a 
service across network boundaries, which is further ex- 
plained as follows. Consider the case when Network B 
is the service provider. Then the service logic program 
for a service is located in SCF 230. To perform the serv- 
ice, SCF 230 would need the call-related information (in- 
cluding the initial query from SSP 214) and SCF 230 
would also need to send instructions to SSP 21 4 as well 
as to SRF 216. Buf SCF 230 cannot perform any of 
these actions, because its only connection is to SDF 220 
and not to any of the network elements that establish 
and maintain the call. If SCF 230 had had an interface 
(via INAP) to SCF 208, some relaying of the call-related 
information between Network A and Network B could 
have possibly remedied the problem (although at high 
performance cost), but such an interface is not support- 
ed by INAP. 

The limitations of the present interconnection ar- 
rangement shown in Fig. 2 will be further illustrated by 
an example. Consider a service provider who desires to 
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provide a service that announces the names of pieces 
of music currently being played by various classical mu- 
sic stations around the United States. The service pro- 
vider desires to advertise an 800 number, which, once 
called, could connect the caller to a platform or device. 
The platform would, in turn, prompt the caller for the 
identity of the station in question (if there are more than 
one classical music station in the caller's area), and, 
based upon the response and information identifying the 
geographical place whence the call comes from, an- 
nounce to the caller the name of the piece currently be- 
ing played (e.g., Prokofiev's Violin Concerto No. 1 ). Cur- 
rently, such a service could be offered only by a network 
provider that owns or controls the whole range of net- 
work equipment. This is because, with the current ar- 
rangement and limitations shown in Fig. 2, the service 
would have to be implemented only on the SCP of the 
network provider. 

A much more optimal way of providing the same 
service, and a way that is much more beneficial to the 
service provider, would be for the service provider, who 
owns just a computer, i.e., an SCP, with the service logic 
necessary for the service and who has a connection to 
the well known SS7 signaling network, to receive an 
INAP query from the first IN switch in which the call orig- 
inates. From this query, the service logic inside the serv- 
ice provider's SCP could detect the geographical place 
whence the call comes from ; check its database, and 
instruct the switch to connect the caller to an appropriate 
device that would prompt him or her to identify the sta- 
tion in question. Based upon the caller's response, the 
piece currently being played (again, based on the data- 
base information) could be identified. The network pro- 
vider in this arrangement would be paid only for the re- 
sources used in the network; in addition, the service log- 
ic could be easily changed by the service provider with- 
out requiring any change to be made to the network. 

Referring now to Fig. 3 : there is shown a diagram 
illustrating the arrangement of a mediation access proc- 
essor (MAP) 304 in accordance with the present inven- 
tion, that acts as an interface between SCF 302 in a first 
network, Network A, and an SSP 306 (including SSF/ 
CCF modules) in a second network, Network B. Note 
that MAP 304 is located in the same network (Network 
B) with SSP 306. MAP 304, although illustrated in a sep- 
arate element, can be easily implemented inside of an 
SCP. 

Functionally, as shown in Fig. 3 : MAP 304 provides 
three separate functions in three modules. First, a 
screening function is provided in screening module 308; 
second, a translation function is performed in translation 
module 310, and third, an emulation function is per- 
formed in emulator module 312. The functionalities of 
each module are described in detail below in connection 
with Fig. 4. 

The MAP 304 of Fig. 3 provides an emulation func- 
tion at the interfaces between SCF 302 and SSF/CCF 
306. that is dependent upon the direction in which sig- 



naling messages are passed between these elements. 
First, MAP 304 operates at the SCF to SSF interface as 
though it is an SSF/CCF, thus using any existing INAP 
option (such as the SSF Application Service Element 

s (ASE), asdescribed in ITU-T Recommendation Q.1 21 8, 
or Bellcore AIN 0.1 option, or ETSI Core INAP option) 
supported by the SCF. Second, MAP 304 operates at 
the SSF/CCF to SCF interface as though it is an SCF, 
thus using any existing INAP option (SCF Application 

10 Service Element (ASE), as described in ITU-T Recom- 
mendation Q.1 21 8, or Bellcore AIN 0.1 option, or ETSI 
Core INAP option) supported by the SSF/CCF, inde- 
pendent of the option used by the other side. For exam- 
ple, the SSF/CCF may use the AIN 0.1 INAP, while the 

is SCP may use ETSI CORE INAP. 

In addition to the emulation function just described, 
MAP 304 performs a translation function if needed be- 
cause of different options in the SCF 302 and SSF/CCF 
306. In addition, it performs a screening function on be- 

20 half of Network B as deemed necessary by the network 
provider wishing to protect the switch and network in- 
tegrity. 

Referring now to Fig. 4, there is shown a block dia- 
gram illustrating the arrangement of the modules within 

25 MAP 304 of Fig. 3. At a high level, it is seen from Fig. 4 
that the MAP has two principal components, namely (a) 
an SCF adapter 421 and (b) an SSF adapter 422. SCF 
adapter 421 and SSF adapter 422 are interconnected 
to each other through a bus 403 which connects both 

30 modules to a protocol coordination function (PCF) mod- 
ule 402, which conveys (and, if necessary, converts the 
format of) the messages between SCF adapter 421 and 
SSF/CCF adapter 422. PCF module 402 just passes the 
messages when no translation is needed, or sends re- 

35 spective error and rejection messages back in accord- 
ance with the error procedures on the respective side. 

A protocol screening module 411 is included in SCF 
adapter 421 in order to protect the network from unwant- 
ed or erroneous (respective to the given state of the net- 

40 work) messages. Protocol screening module 411 sends 
back an error message to the SCF when such a mes- 
sage has been detected. Protocol screening module 
411 is present only within SCF adapter 421 (and not 
SSF/CCF adapter 422) because only the messages 

45 coming from the foreign network need to be screened. 
Implementationally, protocol screening module 411 
can be an associative memory arrangement (or a soft- 
ware implemented memory arrangement) that imple- 
ments a table that identifies set of operations that need 

50 to be screened, and a set of parameters of such opera- 
tions that need to be screened. Whenever and entry in 
the table is found, an appropriate error procedure to 
which this entry points will be invoked. For example, if 
a CONNECT operation with a destination that the net- 

55 work considers undesirable is received, the entry in the 
table in protocol screening module 411 will be found, in 
which an error action (in this case, sending a REJECT 
message to the appropriate protocol identification mod- 
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ule) is specified. 

A protocol identification module 404 is also included 
in SCF adapter 421 , and a similar module, protocol iden- 
tification module 426, is included in SSF/CCF adapter 
422. Each of the protocol identification modules 404 and 
426 receives SS7 signaling messages from the SCF or 
the SSF, as the case may be. performs any necessary 
translations, and sends messages back to the SCF or 
SSF. In order to perform these translations, protocol 
identification module 404 includes a protocol decoder 
412, which, upon receiving a message, determines 
which INAP option should be invoked. Using this infor- 
mation, messages passing through the protocol identi- 
fication module 404 or 426 are routed to one of several 
modules in the protocol identification module. For ex- 
ample, each of the protocol identification modules 404 
and 426 in Fig. 4 includes a first module 406 or 430 
which identifies the CS-1 protocol, a second module 408 
or 432 which identifies the AIN protocol, and a third mod- 
ule 410 or 434 which identifies the Core INAP protocol. 
Other modules may also be provided, and each of these 
modules can be plugged in or reprogrammed to realize 
appropriate INAP options. From the forgoing, it is seen 
that the protocol identification modules 404 and 426 al- 
low the MAP to emulate the SSF/CCF behavior (at the 
SCF interface) and that of SCF (at the SSF/CCF inter- 
face). 

An SS7 adapter 414 is provided between the SS7 
interface 416 that connects the MAP to the SCF This 
interface 416 is responsible for re-formatting messages 
according to the rules of the network protected by MAP 
and the one in which the SCF resides. This reformatting 
occurs, for example, for TCAP messages, and. if nec- 
essary, for SCCP and MTP messages. A local SS7 in- 
terface 440 is provided to interface the MAP with the 
SSF. 

In lieu of the hardware realization of MAP 304 illus- 
trated in Fig. 4, the MAP can also be implemented as a 
software application within a general purpose computer 
It is to be noted, however, that a specialized hardware 
implementation generally results in improved perform- 
ance. 

There are several options that can be taken with re- 
spect to a software implementation of the present inven- 
tion. In the most straightforward embodiment, SCF 
adapter 421 and SSF adapter 422 can be implemented 
as asynchronous processes, such as those that can be 
created within the UNIX® operating system. Protocol 
coordination function (PCF) module 402 can be imple- 
mented as a library of objects that contain (a) coordina- 
tion objects (i.e., semaphores or monitors), as well as 
(b) the set of objects that perform the protocol message 
conversion from a canonic form to a specific form (such 
as CS-1. ETSI Core INAP, etc.) and vice versa. The be- 
havior of the latter objects will then be governed by the 
state machines defined in ITU-T Recommendation Q 
1218. 

The rest of the modules which comprise adapters 



421 and 422 can be implemented as object libraries, as 
follows. The protocol identification modules 404 and 426 
can be implemented as objects with just one state var- 
iable each, which is set by protocol decoder 41 2 to de- 
5 termine which set of the translation routines is to be se- 
lected. SS7 adapter 414 can be implemented as an ob- 
ject with two functionalities, namely (1 ) send and (2) re- 
ceive, the former invoked by protocol identification mod- 
ule 414, and latter invoked by protocol decoder 412. 
10 In addition to the hardware implementation shown 
in Fig. 4, there are other possible hardware implemen- 
tations for the present invention. For example, SSF/CCF 
and SCF adapters 422 and 421, respectively, can be 
implemented as two separate modules with four sockets 
1 5 each : two for connecting input and output to the SS7 
network (or SS7 adapter 41 4, as in the case of the SCF), 
and two more for connecting input and output to the pro- 
tocol coordination function module 402. Alternatively, 
both SSF/CCF and SCF adapters 422 and 421 could be 
20 connected to a bus shared with the protocol coordina- 
tion function module 402-and, possibly, several external 
memory modules and I/O devices). As yet another al- 
ternative, the protocol coordination function module 402 
can be a separate module connected to the SSF and 
25 SCF adapters, as described above. Still further, SS7 
adapter 41 4 can be a separate module connected to the 
SSF adapter as described above. 

Referring now to Fig. 5, there is shown a diagram 
illustrating the process performed in MAP 304 of Fig. 3 
30 when it receives a message from SCF 302 in Network 
A of Fig. 3. The process begins in step 500, in which a 
message is received from the SCF (such as SCF.302 
of- Fig. 3). Next, in step 501 , a determination is made in 
the SS7 adapter 414 as to whether the message is in 
35 local format. If not, the process proceeds to step 502, in 
which a determination is made, also by SS7 adapter 
414, as to whether the message is correctly composed 
in the foreign format. If a NO result occurs, the process 
proceeds to step 515, in which an error treatment is ap- 
*o plied by SS7 adapter 414. This error treatment could 
consist of termination of certain local activities, as well 
as issuing an appropriate error control message to the 
SCF 

If a YES result occurs in step 502, the process pro- 
45 ceeds to step 503, in which the message is translated 
in SS7 adapter 414 to local format for Network B. Next, 
in step 504, a determination is made as to whether the 
message is appropriate in the current state of the rele- 
vant SS7 protocol layer(s). If a NO result occurs, the 
50 process proceeds to step 515, in which error treatment 
is again provided by SS7 adapter 414. 

If a YES result occurs in step 504, the process pro- 
ceeds to step 505, in which a determination is made as 
to whether the application context (or other form of INAP 
55 option ID) is valid? If a NO result occurs, the process 
proceeds to step 516. in which error treatment is provid- 
ed by protocol decoder 516. As in the previous case, 
this error treatment could consist of termination of cer- 
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tain local activities, as well as issuing an appropriate er- 
ror control message to the SCR 

If a YES result occurs in step 505, the process pro- 
ceeds to step 506. in which the appropriate protocol 
module is selected. This can be module 406 ; 408 or 410 
in the embodiment shown in Fig. 4. Next, a determina- 
tion is made in step 507 as to whether the message is 
properly composed and was received in an appropriate 
state of (NAP. If a NO result occurs, error treatment is 
provided by protocol identification module 421 in step 
517. This treatment could involve sending a TC AP reject 
message to the SCR 

If a YES result occurs in step 507, the state of the 
I NAP, as specified in Section 3 of ITU-T Recommenda- 
tion Q.1218, is updated in step 508, and the process 
proceeds to step 509 in which a determination is made 
as to whether the operation specified in the message is 
allowed by this switch. If a NO result occurs, error treat- 
ment is provided by protocol screening module 411 in 
step 518. 

If a YES result occurs in step 509, a determination 
is next made in step 51 0 as to whether every parameter 
value is appropriate for this switch. If a NO result occurs, 
error treatment is also provided by protocol screening 
module 411 in step 518. 

If a YES result occurs in step 510, the process pro- 
ceeds to step 51 1 in which the current message is trans- 
lated into one (or more) other messages, based upon 
the option selected by the SSF/CCF adapter 422. The 
process then proceeds to step 512, in which the trans- 
lated message is sent to the SSR/CCR in this example, 
SSF/CCR 306 of Rig. 3. 

Rig. 6 is a diagram illustrating the process per- 
formed in MAP 304 of Fig. 3 when it receives a message 
from SSF/CCF 306 in Network B of Fig. 3. The process 
begins in step 600, in which a message is received in 
MAP 304 from SSF/CCF 306 of Fig. 3. Next, in step 601 , 
a determination is made as to whether the application 
context (or other form of option id) for this message is 
valid. If a NO result occurs, then error treatment is pro- 
vided in step 602. 

If a YES result occurs in step 601 , the process pro- 
ceeds to step 603, in which the appropriate module (i. 
e., module 430, 432 or 434) in protocol identification 
module 426 is selected. Then, in step 604, the message 
is passed to the protocol coordination function module 
402. Next, a determination is made in step 605 as to 
whether further information from the switch is required 
for the translation. If a NO result occurs, then, in step 
606, a message is sent back to SSF/CCF 306, and the 
state of the system (i.e.. the state of the I NAP, as spec- 
ified in Section 3 of ITU-T Recommendation Q. 1 21 8) is 
adjusted. 

If a YES result occurs in step 605, the process pro- 
ceeds to step 607, in which the message is translated 
and sent to the SS7 adapter 414. Next, in step 608, a 
determination is made as to whether a translation into 
a foreign SS7 format needed. If a YES result occurs, the 
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message is translated into the foreign format in step 
609, and the process proceeds to step 610, in which the 
message is sent to the SCF, in this example, SCF 302 
of Fig. 3. If a NO result occurs in step 608, the process 

5 skips step 609 and proceeds directly from step 608 to 
step 610, as translation is not required. 

Various modifications and adaptations of the 
present invention will be apparent to those skilled in the 
art. For that reason, it is intended that the invention be 

10 limited only in accordance with the following claims. 



Claims 

'5 1. Apparatus for interconnecting first and second net- 
works so that intelligent network services can be 
provided to a caller connected to said first network 
using call processing logic residing in said second 
network, said apparatus comprising 

20 

a least one switch in said first network adapted 
to receive a call from said caller; 

at least one network element in said second 
25 network arranged to store said call processing 

logic: 

a mediation access processor (MAP) located in 
said first network; and 

30 

means for connecting said MAP to said switch 
in said first network and to said network ele- 
ment in said second network: 

3 $ wherein said MAP is arranged so that messag- 

es transmitted between said switch in said first 
network and said network element in said sec- 
ond network are converted So as to be recog- 
nized and understood by said network element. 

40 

2. The invention defined in claim 1 wherein said net- 
work element is a Service Control Point (SCP). 

3. The invention defined in claim 2 wherein messages 
45 between said switch and said MAP are in a first for- 
mat and messages between said MAP and said net- 
work element are in a second format. 

4. The invention defined in claim 3 wherein said first 
so format is AIN 0.1 INAP and said second format is 

ETSI CORE INAP. 

5. The invention defined in claim 1 wherein said MAP 
is disposed within an SCP in said first network. 

55 

6. The invention defined in claim 1 wherein said MAP 
includes a screening module arranged to protect 
the network from unwanted or erroneous messag- 
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es ; and protocol identification and coordination 
modules arranged to translate messages from one 
INAP option to another. 

7. The invention defined in claim 1 wherein said MAP 
operates at the SSF/CCF to SCF interface as 
though it is an SCF, and operates at the SCF to SSF/ 
CCF interface as though it is an SSF/CCF. 

The invention defined in claim 1 wherein said MAP 
includes an SCF adapter and an SSF adapter. 

The invention defined in claim 8 wherein said SCF 
adapter and SSF adapter are interconnected to 
each other through a PCF module that performs a 
protocol coordination function. 



8. 



10. The invention defined in claim 9 wherein said pro- 
tocol coordination function performed by said PCF 
includes translation of one protocol into another 
protocol. 

11. A method for interconnecting first and second net- 
works so that intelligent network services can be 
provided to a caller connected to said first network 
using call processing logic residing in said second 
network, said method comprising the steps of 

receiving a call from said caller in at least one 
switch in said first network; 

storing said call processing logic in at least one 
network element in said second network: and 

connecting a mediation access processor 
(MAP) located in said first network to said 
switch in said first network and to said network 
element in said second network; 
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is disposed within an SCP in said first network. 

16. The method defined in claim 11 further including the 
steps of M 

screening messages in said MAP to protect the 
network from unwanted or erroneous messag- 
es, and 

translating messages from one INAP option to 
another in protocol identification and coordina- 
tion modules. 

17. The method defined in claim 11 wherein said MAP 
operates at the SSF/CCF to SCF interface as 
though it is an SCR and operates at the SCF to SSF/ 
CCF interface as though it is an SSF/CCF. 

18. The method defined in claim 11 wherein said MAP 
includes an SCF adapter and an SSF adapter. 

19. The method defined in claim 18 wherein said SCF 
adapter and SSF adapter are interconnected to 
each other through a PCF module that performs a 
protocol coordination function. 



w 



15 



20 



25 



20. 



30 



35 



The method defined in claim 1 9 wherein said pro- 
tocol coordination function performed by said PCF 
includes translation of one protocol into another 
protocol. 



wherein said MAP is arranged so that messag- 
es transmitted between said switch in said first 
network and said network element in said sec- 
ond network are converted so as to be recog- 
nized and understood by said network element. 

12. The method defined in claim 11 wherein said net- 
work element is a Service Control Point (SCP). 

13. The method defined in claim 12 wherein messages 
between said switch and said MAP are in a first for- 
mat and messages between said MAP and said net- 
work element are in a second format. 

14. The method defined in claim 13 wherein said first 
format is AIN 0.1 INAP and said second format is 
ETSI CORE INAP. 

15. The method defined in claim 11 wherein said MAP 
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